The commercial importance of a high-performance and high-capacity database systems has resulted in a rapid proliferation of approaches by multiple vendors to supply high-performance and high-capacity database solutions. Over time, however, some of the plethora of approaches are amalgamated into fewer approaches. For example, users of multiple database systems in an enterprise may coalesce into fewer or even a single database system for ongoing operations. Or, one enterprise using a particular vendor's database system may be acquired and/or merged into another (e.g., larger) enterprise using a different vendor's database system. In many cases persistent data from one database system can be migrated into various forms of persistent data of another database system. Unfortunately, differing approaches by multiple vendors has resulted in a proliferation of dialects of SQL languages. Still, the strong need to coalesce multiple database systems into fewer or even a single database system for ongoing operations coupled with the very expensive and intractable technique of manual translation has precipitated vendor development of various techniques intended to facilitate coalescing activities.
In an environment having a source database with source applications (e.g., a foreign environment) that need to be coalesced into a target database (e.g., a native environment), several fully- or partially-automated techniques have been proposed and used singly and in combination, for example:                Manually recompile the foreign applications under the native environment.        Manually translate the foreign SQL language constructs into native SQL language constructs.        Manually or semi-automatically translate the foreign database data itself into a corresponding native database.        
Yet, the foregoing techniques cover only some of the possible origins of foreign SQL language statements. For example, foreign applications may assemble queries during run-time—such queries are available nowhere in complete form until run-time, so it cannot be known until run-time that there is such a query to be translated. Worse, legacy implementations cover only some of the possible constructs of foreign SQL language statements. Thus the legacy techniques to coalesce are in need of improvements, at least to provide fully- or partially-automated techniques for translating foreign SQL language statements into native SQL language statements (e.g., for translating foreign SQL into native SQL) regardless of the origin and regardless of the nature of the constructs of foreign SQL language statements.
Therefore, there is a need for an improved approach.